Anycast is a routing method for sending traffic to the nearest servers using the same IP. So here when you connect to 1.1.1.1 it goes to the closest servers. And when you connect to it over a VPN it goes to the closest servers to the other end of the VPN. That's important because if you check the resolve location it appears to be close the VPN location which is your source IP. Differences there can be used to detect connections using a VPN.

@dennypage said in What is it? 25.11.a.20250916.0600: Dev build for 25.11: https://forum.netgate.com/post/1225827 The .a is an alpha release AFAIK.

Mmm, it does seem like a bug. I'm surprised there isn't something open for it. I'll try to replicate it here and open something.

@rcfa They support ARM on Amazon: https://docs.netgate.com/pfsense/en/latest/solutions/aws-vpn-appliance/ I have no insight into Netgate's plans of course, but so far ARM support has been for Plus so I don't expect a CE ARM version if that's what you're asking.

@stephenw10 said in Subnet Mask Update: You need to set the subnet mask on everything static in the subnet. You probably still have somethings set to /24 creating route asymmetry when they try to use their gateway instead of sending directly. Everything appears to be working correctly now. I think this was it. I have an UnRaid server that I thought I changed the subnet mask but it didn't change. Actually have to stop the array and change it. After doing this, I'm back in business!

You can just set the log level to query info in the Unbound advanced setting tab.

Safest way is to backup the config from https://<your-firewall-ip>/diag_backup.php. Edit it then restore the config. That way pfSense will refuse to import it of you have typo'd something. Look in the config for the widgets section like: <widgets> <sequence>system_information:col1:open:0,disks:col1:open,interfaces:col2:open:0,services_status:col2:open:0,gateways:col2:open:0,snort_alerts:col2:open:0</sequence> <period>10</period> <gateways-0> <descr><![CDATA[Gateways]]></descr> <display_type>both_ip</display_type> <gatewaysfilter>WAN_DHCP6</gatewaysfilter> </gateways-0> </widgets> Remove the disks widget. So there I would remove: disks:col1:open, But the widget should be fine with just a ZFS mirror. What do you see from?: zfs list; mount -p; geom disk list;

Ok that will be useful. Also see if you can try running a dtrace whilst sending a failing large ping. So you'll need two ssh sessions open it, for the trace and for the ping. In the dtrace session run: dtrace -n 'fbt::if_inc_counter:entry / arg1 != 0 && arg1 != 2 && arg1 != 5 && arg1 != 6 / { printf("%s type %d count %d", ((struct ifnet*)arg0)->if_xname, arg1, arg2); stack(); }' Then send some large pings in the other session that should work but fail. Stop the dtrace with ctl+c after a few pings and see what's shown.

@azalea said in IPv6 Link Local in Interface Status: On the other hand, the OPT1 interface status display, NDP table display, and ifconfig execution results all show that the OPT1 interface (IPv6) is linked to "fe80::XXXX:XXXX:XXXX:XXXX%pppoe1 From the Wikipedia article: Even if a single address is not in use in different zones, the address prefixes for addresses in those zones may still be identical, which makes the operating system unable to select an outgoing interface based on the information in the routing table (which is prefix-based). [In this specific case, your WAN interface's link-local address of fe80::[EUI-64]/128 is the 'prefix' being referred to here] In order to resolve the ambiguity in textual addresses, a zone index must be appended to the address. [ . . . ] As multiple interfaces may belong to the same zone (e.g. when connected to the same network), in practice two addresses with different zone identifiers may actually be equivalent, and refer to the same host on the same link. fe80::[identical EUI-64]%ppoe0 and fe80::[identical EUI-64]%em0 are obviously not mutually exclusive addresses, even if both or neither are active at any given time on a given link. And the zone index in general can obviously refer to both, a physical or a logical network interface. The same goes for fe80::[identical EUI-64]%ppoe1 and fe80::[identical EUI-64]%em1 on the OPT1 interface. Agreed no problem here, just thought-provoking discussion (at least for me!) of an interesting IPv6 feature.

Ah, interesting. Yup AT&T expect to see their own router at the end of GPON/XPON and pfSense could well be doing something that doesn't play well. Obviously it still shouldn't panic like that. The panic appears to be caused by a race condition during removal of an IPv6 address. If the WAN was renewing a lease repeatedly that seems likely.

So you upgraded the secondary to 25.07 and it didn't hit the same issue?

Hmm, well it should start at boot. If it fails to start I'd expect some error to be logged.

You could try an afterfilterchange shellcmd to trigger a script. That would be triggered when any tunnel comes up.

Hmm, OK. Not much to go on in that report unfortunately. If it does crash again comparing it would be useful. I'll see if anyone else sees anything I'm missing.